fix(websocket): reconnect after clean server close (INT-1697) - #751

Why

A server-initiated clean WebSocket close (1000 or 1001) can stop a long-running Python agent rather than reconnect it. This was reproduced with band-sdk 4.0.0 through a fault proxy, and a production close 1000 previously left an agent unable to receive messages for roughly 34 hours. An abnormal close or service-restart close (1012) does reconnect.

Proposed behavior

• Retry server-initiated 1000/1001 unless the agent received a terminal agent_control:supersede push.
• An intentional local disconnect() remains terminal.
• NOT YET IMPLEMENTED: a rejected reconnect due to authentication must stop retrying, rather than loop indefinitely. The Phoenix dependency's post-connect supervisor catches the handshake rejection internally; the SDK's initial-connect classifier is not invoked. This is a merge blocker, not a passing property of this draft.

Policy decision for SDK owners: Is server-initiated 1001 reconnectable absent a terminal push, as the platform WebSocket contract specifies? This draft proposes yes. A lost supersede push can cause retries, so cooldown and Retry-After handling need explicit review. This reverses the test-only, unmerged #441 proposal that pinned both 1000 and 1001 terminal.

Scope and limits

This is a focused SDK reconnect-policy change, not a replacement for Session ownership of the Phoenix client's post-connect retry loop (INT-1355). The gateway's independent dead-link watchdog remains a backstop. A September lab stop produced 1000, whereas an October three-node rolling stop produced 1012; production deploy close codes have not been independently confirmed. Do not interpret this PR as evidence that every deployment triggers the bug.

Tracking: INT-1697; gateway report #43; platform follow-up PLT-1573.

Verification

• PASS: real Phoenix fake-server regression for server close 1000/1001 (observed RED on base, GREEN with policy), terminal supersede, and intentional local disconnect.
• PASS: 151 targeted WebSocket/platform tests; Ruff check and format on changed files; targeted Pyrefly on production client (0 errors).
• FAIL (merge blocker): a real-client fault probe connected, received server close 1001, then got 401 or 403 on reconnect. In both cases it made three upgrade requests (initial success + two rejected attempts), so terminal auth handling is not established. The exploratory probe was not retained as a permanent regression test; it must be added with the fix.
• NOT RUN: production deploy close-code capture and live disabled-account reconnection.
• BLOCKED for merge: add a post-connect auth rejection signal/terminal handling at the Phoenix-client boundary (or complete INT-1355's SDK-owned reconnect loop), then retain a failing-before/green-after real-wire test. SDK-owner policy sign-off for 1001 is also pending.